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Abstract. In the area of networks, a common method to enforce a secu- 
rity policy expressed in a high-level language is based on an ad-hoc and 
manual rewriting process [24]. We argue that it is possible to build a for- 
mal link between concrete and abstract terms, which can be dynamically 
computed from the environment data. In order to progressively introduce 
configuration data and then simplify the proof obligations, we use the B 
refinement process. We present a case study modeling a network mon- 
itor. This program, described by refinement following the layers of the 
TCP/IP suite protocol, has to warn for all observed events which do 
not respect the security policy. To design this model, we use the event- B 
method because it is suitable for modeling network concepts. 
This work has been done within the framework of the POTESTAT^ 
project [9], based on the research of network testing methods from a 
high-level security policy. 
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1 Introduction 

The separation between policies and mechanisms is considered as a main spec- 
ification principle in security. The policy describes the authorized actions while 
the mechanism is the method to implement the policy [24, 17]. Those two con- 
cepts do not have the same abstraction level. The classical process to enforce a 
policy consists of manually rewriting the policy in the same terms as the mech- 
anism, with ad-hoc methods. We argue that a policy can be formally enforced 
in a mechanism by gradually building, through a refinement process, a link be- 
tween abstract and concrete terms. We propose to design a specification with 
the same abstraction level as the policy and to refine it to obtain the concrete 
mechanism. In the case of critical software, using an abstract specification is, for 
example, required for test and audit processes or for certification according to 
the Common Criteria [7]. 

To illustrate our approach, we describe a network security software which has 
to enforce an abstract security policy in a TCP/IP network. Modern TCP/IP 
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networks are heterogeneous and distributed, and their management becomes 
more and more complex. Thus, the use of an abstract security pohcy can give 
a global and comprehensive view of a network security [22]. We choose to focus 
more specifically on an access control policy because it is the main concept in 
network security [10,20]. 

We aim at designing a monitor, which warns if an action, forbidden by the 
policy, is observed on the network. In order to achieve that, we use the event-B 
method [1] for modeling network concepts. 

The next section is an overview of the event-B method. Section 3 intro- 
duces networks and their security policy concepts. Then, Section 4 presents our 
approach, Section 5 describes our method based on the refinement process. Sec- 
tion 6 is a presentation of the case study. Finally, we conclude by comparing this 
work to related ones and by giving some prospects. 

2 Event-B 

The B method [2] is a formal development method as well as a specification 
language. B components can be refined and implemented. The correctness of 
models and refinements can be validated by proof obligations. 

Event-B [1] is an extension of the B language where models are described 
by events instead of operations. The most abstract component is called system. 
Each event is composed by a guard G and an action T such that if G is enabled, 
then T can be executed. If several guards are enabled at the same time then the 
triggered event is chosen in a nondeterministic way. 

Through the refinement process, data representation can be changed. The 
gluing invariant describes the relationship between abstract and concrete vari- 
ables. If an event ca is refined by an event en, then the refinement guard has 
to imply the abstract one. Moreover, some events can be introduced during the 
refinement process (refining the skip event), according to the same principles as 
the stuttering in TLA [15]. Due to the guard strengthening through refinement 
process, we have to prove that there is always at least one enabled event (no 
dead-lock) and that new events do not introduce live-locks. 

To conclude. Table 1 defines the set notations which are used thereafter and 
Table 2 summarizes generalised substitutions. 



Operator 


Meaning 


B 


= {R\ RCAx B} 


dom(_R) 


= {a 1 36- ((a, b) G R)} 


ran(_R) 


= {b 1 3a-{{a,b) e R)} 


R[A] 


= {b\3a-{a€ A A (a,6) G R)} 


R-^ 


= {(6, a) 1 {a,b)eR} 


Ri ; i?2 


= {ia,c) \3b- {{a,b) e Rl A ib,c) e R2)} 


Rl II i?2 


= {{{a,b),{c,d)) \ (a,c) € Rl A {b,d) & R2} 


Rt> B 


= {(a,fe) \[a,b) eR A b e B} 


Ai^ B 


= {F \ F eA^B A V(6i, 62) • ((a, 61) G F A (a, 62) G F ^ fei = 62)} 



Table 1. Used sets operators 



Substitution 


Syntactical notation 


Mathematical notation 


Do nothing 
Assignment 
Unbounded choice 
Condition 


skip 

x:= E 

ANY Z WHERE P THEN T END 
IF P THEN Ti ELSE T2 END 


skip 

X-- E 

@z-{P^ T) 

P^Ti\^P=^T2 



Table 2. Used primitives substitutions 

3 Introduction to Networks and their Security Policies 
3.1 The TCP/IP Protocol Suite 

Computer networks use a standard connection model, called OSI (Open Systems 
Interconnection) [13], composed of seven layers. The TCP/IP protocol suite im- 
plements this model but is described with only four layers: application, transport, 
network and link. Each of these layers plays a particular role: 

— The Application layer is the interface between the applications and the net- 
work (client-side protocol). 

— The Transport layer manages the host-to-host communications, but not the 
route between them (peer-to-peer networks). 

— The Network layer manages the route between networks by selecting the 
network interface to use and the first router. 

— The Link layer performs the signal translation (analogic/numeric) and syn- 
chronizes the data transmission. This layer is most often provided by the 
hardware. Therefore, it is not considered in the following sections. 
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Fig. 1. Layers of the TCP/IP suite with some examples of protocols. 

Communications using TCP /IP protocol are composed of protocols for each 
layer in the suite. For example, a TCP datagram (Transport layer) is contained 
in the data field of an IP packet (Network layer). Figure 1 shows an example of 
communication using TCP/IP. 



3.2 Network Security Policies 



In the area of networks, security is mainly expressed in terms of access riglrts. An 
access control policy is defined on a set of actions by a set of rules. These rules 



determine, for each action, whether the action is authorized or not. Among the 
various types of access control pohcies [11, 16], open policies and closed policies 
can be distinguished. An open pohcy (Fig. 2. A) expresses aU forbidden actions 
(called negative authorizations): a not explicitly denied access is allowed. In a 
closed policy (Fig. 2.B), all authorized actions have to be fully specified (called 
positive authorizations). Finally, some policies arc expressed with both positive 
and negative rules (Fig. 2.C). In this case, some actions can be conflicting or 
undefined. 



Forbidden actions 
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A. Open policy B. Closed policy C. Both policies 

Fig. 2. Example of open, closed and both policies. 

In the following, readers should distinguish network events, which are the 
elementary communication steps of the network, and B events, which are the 
description of actions in the B method. 

In the proposed approach, a closed policy defined by a single set {SP) of 
authorized actions is used. However, each of these abstract actions can be asso- 
ciated to one or more concrete network events and conversely. 

Definition 1 (Types of Events). An event is correct with regard to a security 
policy if it corresponds only to authorized actions of the policy (Fig. 3. A). If the 
event is associated only to forbidden actions then this event violates the policy 
(Fig. 3.B). If an event is linked to some authorized actions and to some forbidden 
ones, then this event is in conflict with the policy (Fig. 3.C). 





A. Correct with regard to SP B. Violates SP C. In conflict with SP 

{Pass status) {Fail status) {Conflict status) 

Fig. 3. Events correct with regard to SP, in violation of SP or in conflict with SP. 

Several conformity relations [11, 19] can be used when conflicting events can 
occur. The approach proposed in this article is the following: 

Definition 2 (Network Conformity). A network conforms to a security pol- 
icy if each event of this network is correct with respect to the policy. 

Finally, if a security policy is relevant only to a part of the network, then all 
events that are not associated to any action of the policy are unspecified. 



4 Policy Security through TCP/IP Levels 
4.1 Traceability from Policy to Implementation 

The proposed approach aims to express a security policy at an abstract level 
(on actions) and to preserve it through the refinement process until its imple- 



mentation (on network events). However, each refinement level can only access 
information from the protocol header of the corresponding TCP/IP layer (Fig. 1) 
and has to implement the same security policy as the specification. 

The model used to illustrate this approach is a monitor. A monitor has to 
detect at least each network event which violates SP or which is in confiict with 
SP. In the ideal case, no event correct w.r.t. SP is detected. The monitor has 
then to guarantee, at each refinement level, the next two properties: 

Property 1 (Monitor Correctness) 

Each event that is not detected is correct with respect to the security policy. 
Property 2 (Monitor Completeness) 

Each event that is detected violates or is in conflict with the security policy. 

In the model, the network events representation gradually changes at each 
refinement (from actions to concrete events). To implement these properties, the 
link between the different representations has then to be modeled, in a systematic 
way, at each refinement level. So, the end user (the administrator of a network) 
can choose the abstraction level of his policy (by using or not the more abstract 
levels of the model) and each event is traced through the refinement, as needed 
for some certification process such as the one of the Common Criteria [7] . 

Each refinement level represents how the communication is seen between two 
elements of the network. At level 0, events correspond to the access by a user to 
a service. They are considered as actions of the security policy. At level 1, events 
are messages between daemons {Application layer). At level 2, events are requests 
between hosts and are attached to particular ports (Transport layer). At level 3, 
each event is a connection between interfaces and is attached to particular ports 
(Network layer). Table 3 summarizes these different representations. 



Level of specification 


Network concepts 


TCP/IP layer 


(Policy level, actions) 

1 

2 

3 (implementation) 


Users, services 
Daemons, Terminal servers 
Hosts, ports 
Interfaces, ports 


Application 

Transport 

Network 



Daemon: software server providing some services. 

Terminal server, particular daemon providing some logging services. 

Host: machine of the network. 

Ports: channels associated, on each host, to zero or one daemon. 
Interface: network interface (e.g. a network card). 



Table 3. Networks concepts by refinement level 

These network concepts can be extracted from information contained in con- 
figuration files. For example the list of registered Linux users can be found in the 
/etc/passwd file and the list of daemons hosted on each machine can be found 
in /etc/init .d/. This information can then be used to associate each network 
event to an action of the policy. 



Finally, an observer is introduced in the model to give the internal status 
{Pass, Fail or Conflict - Fig. 3) associated to each observed network event. As 
the event representation changes through the refinement process, the parameters 
of the observer are described in global variables. 

4.2 Example 

To illustrate the notions of conflict and failure, here is a short example (Fig. 4) 
of a monitor that receives a copy of each message from the network and that is 
parametrized by a security policy and the network configuration. 

SP = { ( James, Intranet) , 
{James, Mail), 
{Alice, Mail)} 
Security policy 



Hosti is used by James or Alice 
Intranet is hosted on the port 80 from Hosti 
Mail is hosted on the port 993 from Host2. 
Network installation Network configuration information 

Fig. 4. Example of the monitor installation 

A message coming from Hosti and going to Host2 at port 80, is necessar- 
ily sent by James or Alice, because they are the only referenced Hosti users. 
Moreover, due to the accessed port of Host2, and according to the configuration 
information, the service can only be the Intranet. However, the security policy 
SP only allows James to access to the Intranet. Thus, the observed message is 
in Conflict. 

Now, if the message comes from Hosti and goes to port 993 of Host2, then 
the accessed service is Mail and all the users of Hosti are authorized to access 
it. Therefore, this message is correct w.r.t. the security policy {Pass case). 

Finally, if a message is exchanged with a host {Host^) which is not in the 
described part of the network, then no user or action is associated to it by the 
network configuration: the event is ignored. 

5 Description of Refinement Levels 

As previously said, each refinement level represents a different layer of the 
TCP/IP protocol suite (Table 3). In the first subsection, we define the data do- 
main attached to each refinement level. Next, we present a systematic approach 
to model the links between refinements, based on configuration files. Then, we 
introduce journals in order to establish the monitor correctness and complete- 
ness properties (Properties 1 and 2). Finally, we describe the observer allowing 
to trace the status of each event through the refinement process. 




5.1 Events Representation 

Table 4 gives the representation of the events for each refinement level, according 
to the network concepts presented in Table 3. Moreover, the incoming ports are 
modeled while the outgoing ports are not so (Levels 2 and 3, Table 4). Outgoing 
ports are useless as long as the history of connections is not taken into account. 
Indeed, outgoing ports are dynamically and randomly chosen and cannot be 
used to identify a daemon or a user, contrary to the incoming ports, that are 
statically reserved for each service (managed by the lANA^). 

Level of specification Network events representation 

(Policy level) Neto = USERS x SERVICES 

1 Neh = DAEMONS x DAEMONS 

2 Net2 = HOSTS x {HOSTS x PORTS) 

3 (Implementation) Nets, = INTERFACES x [INTERFACES x PORTS) 

Table 4. Network events representation for each refinement level 

The policy is enforced only on the known part of the network. The constant 
KnownNeti represents the known network subset at each level i. Each set is 
divided into a known and an unknown part, as follows: 

Known Network Definition: 

Users C USERS A Services C SERVICES A Daemons C DAEMONS A Hosts C HOSTS 
A TerminalServers C Daemons A Ports C PORTS A Interfaces C INTERFACES 

A KnownNetQ = Users x Services 

A KnownNeti = TerminalServers x Daemons 

A KnownNet2 = Hosts x {Hosts x Ports) 

A KnownNeti, = Interfaces x {Interfaces x Ports) 

These abstract sets correspond to concrete data extracted from configura- 
tion files. Finally, the security policy is described by the constant set SP of all 
authorized actions of the known network. 

Security Policy Definition: 

SP C KnownNeto 



5.2 Representation Relation 

The event representation changes through the refinement process. The relation 
Represents ^ defines the representation link between the i*'' and {i — 1)*'' refine- 
ment levels. For example. Represents^ associates each terminal server to a set of 
users and each daemon to a set of services. Note that Represents.^ is a relation 
and not a function because a concrete event is not always associated to a single 
abstract event (as seen in the example from Section 4.2). It is neither a function 
from KnownNeti-i to KnownNeti because an action can be associated to sev- 
eral concrete events. These relations can be composed to define Represents ^..^q 
between the i*'' level and the policy level. 



^ lANA = Internet Assigned Numbers Authority 



Representation Relation ELxioms: 

Represents^ £ KnownNeti -f^ KnownNeti-i (with iGl..3^ 

A Represents £ KnownNeti ^ KnownNeto ( with i (E 1..3^ 

A Represents — {Represents ^■, Represents . . . ; Represents-^) (with i G 1..3 ) 

In order to simplify some further invariants, we define Represents^ as the 
identity (id(A'^eto))- Finally, each element mentioned in the configuration has to 
be associated with at least one action and one network event: 
The Described Sub-Network is Known as a Whole: 

Aom{ Repres ents ^) — KnownNeti A ran(Represents^) = KnownNeti-i 

5.3 Journalizing Observed Events 

Three journals are maintained: the one of observed events (Monitoredi) and two 
other ones of warned events {FAILi and CONFLICT i respectively for the events 
which violate and are in confiict with the policy) . All these journals are defined 
as non-ordered sets, because the considered policy does not take into account 
the history. Moreover, all warned events are observed and all events observed in 
a concrete level are also observed in the abstract level. At the policy level, no 
confiict can occur, then CONFLICT^:) is empty. 

Invariant (General Journals Definition) 

Monitoredo C KnownNeto 

A Monitoredi Represents~^[Momtoredi-i] (with i G 1..3) 

A CONFLICTo = 

A FAILi U CONFLICT i C Monitoredi (with i G 0..3J 

A FAILi n CONFLICTi = (with i G O..3) 

Properties 1 and 2 can be expressed on these journals, by the next two invariants: 

(1) All observed events associated with Pass status are correct w.r.t. SP: 

Invariant (Monitor Correctness - Property 1) 

Represents ^^^[Monitoredi ~ FAIL, - CONFLICTi] <Z SP (with i G 0..3) 

(2) No event associated with Conflict or Fail status is correct w.r.t. SP: 

Invariant (Monitor Completeness - Property 2) 

Represents i^alFAIL^] D SP ^ (with i G 0..3 ) 

A Ve, • (e, e CONFLICT, ^ Represents ^_o[{e,}] g SP) (with i G O..3} 

5.4 Observer Introduction 

The B event Getstatus is an observer of the network events. It returns the status 
of an event chosen in a nondeterministic way. Because of the change of event 
representation, the observer is modeled with two new global variables: ObsEvent 
and Obsstatus- ObsEvent is the chosen observed event {ObsEventi G KnownNeti) 
and Obsstatus is its status {Obsstatusi G {Pass, Fail, Conflict}). Fig. 5 gives the 
general implementation of the observer Get.status. 

The variables Obs Event and Obsstatus arc defined at each refinement level 
with the following invariant: 



Get_status = any where e Momtoredi then 




IF ei G F^/ii THEN ObsEventi ■- ei Obsstatusi 




ELSIE Ci e CONFLICT I THEN ObSEvcnti ~ ei 1 Obsstaiiisi 


~ Conflict 


ELSE ObSEventi ~ ei ObSStatusi 


:= Pass 


END 




END 





Fig. 5. General definition of the Get^status event 



Invariant (Observed Variables) 

Monitoredi / 

{{ObSstatuB^ = Fail) ^ {ObSEv^ut^ G FAILi)) 

A {{Obsstatus, = Conflict) ^ {ObSEvenH G CONFLICT,)) 

A ((06sst„t„si = Pass) « (06ss„,„ti G Momtoredi - FAIL, - CONFLICTi)) 
The observed event is traced through the refinement process: 

Invariant (Relation through Refinement) 

[ObsEventi, ObsEvmti^i) G Rcprescnts ^ 

Finally, correctness and completeness of the monitor (Properties 1 and 2) are 
implemented on the journals with the invariants defined in Section 5.3. However, 
these properties can also be checked on the observed variables. So, if the following 
assertions hold, then Properties 1 and 2 are verified: 

Assertion 1 (Monitor Correctness on Observed Variables) 

Momtoredi / A Obsstatusi ~ Pass => Obsstatusi-i = Pass (with i G 0..3) 

Assertion 2 (Monitor Completeness on Observed Variables) 

Monitoredi 9 ^ (with i e 0..3) 

[Obsstatusi = Fail Obsstatusi-i = Fail) 
A {Obsstatusi = Conflicts Represents -^f^llObsEventi}] 2 SP) 
A {Obsstatusi^ Conflicts Represents ■^f^[{ObsEventi}]r\SP ^<l)) 

Therefore we only discuss the verification of those assertions that are suffi- 
cient to show Properties 1 and 2. 

6 Model Description 

In the previous section, we have presented, in a systematic way, all data required 
for the model development. In this section, we describe successively each level 
by introducing: the configuration data, the B events and the construction of 
the Represents^ relation. All invariants and properties described in the previous 
section are included at each description level. 

In this description, we also focus on the verification of the correctness and 
the completeness properties of the monitor by checking Assertions 1 and 2. 

6.1 Level 0: User-Service View 

The SP constant set is given by the user while constants Users and Services are 
retrieved from configuration files. Journals are represented as abstract variables 



and are empty in the initial state {Monitored^ := and FAILo := 0). Con- 
sequently, the observed variables are initially undefined (ObsEvento Neto A 
Obsstatuso :G {Pass, Fail, Conflict}). If an event cq occurs on the network then: 

— if eo is not in the observed sub-network then Event^filter (Figure 6.B) is 
launched and bq is ignored, 

— else Check^event (Figure 6. A) is launched and eg is stored in Monitored^. 
Moreover, if eg violates the policy then it is journalized in FAILq. 



Check.event = ANY eo where eo £ KnownNeto then Event.filter = any eo 
Monitoredo := Monitoredo U {eo} || where eo £ Neto 

IF eo ^ SP THEN FAILq :— FAILo U {eo} end A eo KnownNeto 

END THEN skip END 

A. Check.event B. Event.filter 

Fig. 6. Code of B events Cfieck.event and Event.filter at the policy level. 

Finally, this level establishes Properties 1 and 2 by verifying Assertions 1 and 2 
with the observed variables only, since there is no conflict at this level. 



6.2 Level 1: Servers View 

According to Table 3, the daemons sets (Daemons and Terminals ervers) are 
now described. The relation between this level and the more abstract one, i.e. the 
policy level, is extracted from configuration files. Each daemon is configured with 
its registered users and its provided services. We model this information with 
two relations (Provide and Used-By) describing which user can be connected to 
a particular terminal server and which daemon provides a particular service. For 
example, the registered users list of a telnet server can be found in /etc/passwd. 

Represents^ Definition: 

Used.By £ Terminals ervers -fT- Users A Provide £ Daemons o Services 
A Represents^ = (Used.By \\ Provide) 

Check.event = ANY ei where ei £ KnownNeti then Event.filter = ANY ei 

Monitoredi := Monitoredi U {ei} || where ei G Neti 

LET Eo be Eo = (Used_By ]| Provide)[ei] in A ei ^ KnownNeti 

IF Eq n 5P / then then skip end 
FAILi ■- FAILi U {ei} 

ELSIF Eo % SP then 

CONFLICT I ■- CONFLICT I U {ei} 

END 
END 
END 

A. Check.event B. Event.filter 

Fig. 7. Code of the B events Check _event and Event .filter at level 1. 



The journals and the observed variables are defined according to the invari- 
ants given in Section 5. At this level of refinement, the relation RepresentSi is 



used dynamically by the B event Check_event (Figure 7. A) to compute the sta- 
tus of the observed network event, while the B event Event_filter (Figure 7.B) 
ignores all messages exchanged with the unknown part of the network. 

The observer refinement (Fig. 5) produces 18 proof obligations, which, asso- 
ciated to the three ones generated for Assertions 1 and 2, establish Properties 1 
and 2 on the model. 

6.3 Level 2: Hosts View 

As described in Table 3, this level introduces the notions of Hosts and Ports. The 
relation between these concepts and the daemons is extracted from hosts con- 
figuration information. They are summarized by two functions: Hosting, which 
associates the hosts to the daemons, and Run-on, which precises the ports used 
by a particular daemon on a host. Configuration data is such that: 

Represents2 Definition: 

Hosting £ Hosts Daemons A Run-on G Hosts x Ports -H- Daemons 
A RepresentS2 ~ {Hosting > Terminals ervers) \\ Run_on 

Just as in previous levels, the journals and the observed variables are defined 
according to the invariants given in Section 5. The relation Represents 2 is used 
by Check^event (Figure 8. A) to compute the status of the observed network 
event, while Event_filter (Figure 8.B) ignores all messages exchanged with the 
unknown part of the network. 

The main contribution of this level is the implementation of the Check^event 
event (Figure 8. A), which progressively refines the method to compute the Eq 
set of all actions associated to the observed network events 62. 

Check.event = ANY 62 where 62 € KnownNet2 then 
Monitored2 := Monitored2 U {62} || 

let El BE El — {{Hosting > Terminals ervers) \\ Run_on)[{e2}] in 
LET £"0 BE Eo = {Used.By \\ Provide)[Ei] in 

IF So n 5P / THEN 

FAH2 ■- FAH2 U {62} 

ELSIE Eo % SP THEN 

CONFLICT2 ■- CONFLICT2 U {ea} 

END 
END 
END 
END 

A. Check.event 

Event.filter = ANY 62 where ei G Net2 — KnownNet2 then skip end 

B. Event.filter 

Fig. 8. Code of the B events Check_event and Event.filter at level 2. 

In the same way as in the previous level, Properties 1 and 2 are established 
by proving the three proof obligations generated for Assertions 1 and 2 and the 
32 proof obligations generated for the observer event Get status. 



6.4 Level 3: Implementation 



At this level, hosts are valuated into their IP address (32 bit natural which 
identifies hosts for the Network layer) and ports remain unchanged. For example, 
the host anchieta.imag.fr can be valuated into its IP address 129.88.39.37 by 
using its 32 bit natural value^: 2170038053. 

The Represents-^ relation is thus the identity and all invariants are inherited 
and do not need to be proven again. All other constants (security policy and 
configuration information) have also to be valuated. Network parameters can be 
retrieved in configuration files while the security policy has to be given by the 
administrator. Table 5 gives some concrete examples for Fcdora-Core (a Linux 
distribution) of files containing usable data. 



Refinement level 


Constant 


Data file 


(Policy level) 

1 

2 

3 (Implementation) 


Users and Services 
Provide and Used.By 
Run-on and Hosting 
Interfaces 


/etc/passwd and /etc/init.d/ 
Configuration files of each server 
/etc/services and /etc/init.d/ 
/etc/hosts 



Table 5. Example of configuration files for Fedora-Core system. 



However, the event- B language cannot be directly implemented. The model 
is translated into classical B. This transformation is done by some ad-hoc meth- 
ods based on the results of the MATISSE^ project [6,3]. Since the guards of 
Event^filter and Check^event are disjoint, the events are replaced by the single 
operation Check _eventM,nd_Event_filter (Fig. 9). Moreover, the network event 
63 chosen in the guard any 63 where 63 G Net^ is replaced by three input 
parameters IPi, IP 2 and Po representing respectively the IP address of the two 
hosts and the incoming port. 

Check_event-and_Event_filter{IPi, IP2, Po) = begin 
/* Typing precondition: (/Pi, {IP2,Po)) G Nets */ 
VAR trap IN 
tmp < — Is_In_KnownNet{IPi, IP2, Po) ; 

IF tmp =TRUE THEN /* Case of Check.event */ 

Src ■- IPi ; Dest ;= IP2 ; Port := Po ; 
tmp i — Is.e3.0ut.0f.SP(IPi, IP2, Po) ; 
IF tmp =TRUE THEN Status := Fail ; WriteFail{IPi, IP2, Po) 

ELSE 

tmp < — Is.e3Jn.SP{IPi,IP2, Po) ; 

IF tmp =FALSE THEN Status := Conflict ; WriteConflict{IPi, IP2, Po) 
ELSE Status := Pass end 

END 

END /* Else case of Event .filter: skip */ 

END 
END 

Fig. 9. Implementation of the B event Check.event. 
^ 2170038053 = ((129 * 256 + 88) * 256 + 39) * 256 + 37 

* Methodologies and Technologies for Industrial Strength Systems Engineering (MA- 
TISSE): 1ST Programme RTD Research Project (2000-2003). 



Figure 9 is the implementation of Check _event_and_Event_filter operation. It 
uses three local operations {IsJn_KnownNet, Is_e3_0ut_0f_SP and Is_e3Jn_SP) 
to compute the correctness of each observed event. These operations are imple- 
mented as refinements of the corresponding parts of Check_event at level 2. For 
example, the local operation Is_e3 -Out_Of SP is defined in Figure 10. 



rr i — Is_e3.0ut_Of.SP{IPi,IP2,Po) = 




PRE (/Pi, {IP2,Po)) e KnownNets then 




rr — hoo\{{Used_By \\ Provide)[ 


/*RepresentSi[*/ 


{{HostmgO TerminalServers) \\ Run_on)[ 


/* Represents^ [ */ 


{{IP,,{IP2,P0))} 


r {{ip,,{iP2,po))}v 


] 

] n S'P = 0) 


/* ]*/ 


END 





Fig. 10. Abstract definition of the Is_e3 -Out^Of SP local operation. 



The Monitoredi set. modeled to store the monitored events, is not imple- 
mented, while FAIL and CONFLICT sets are stored in files. That is managed 
by an external component providing the operations WriteFail and Write Conflict. 
However, Properties 1 and 2 still hold, since the observed variable Obsstatus2 
and ObsEvent2 remain unchanged. 

Finally, constants (configuration data and security policy) are exported in 
an external component as shown in Fig. 11. Thus, the model is generic and can 
be completely proved independently of the configuration data. The user just 
needs to provide some network information, or to retrieve it from configuration 
files, and to fulfill the conditions on configuration stated in Sections 5.3 and 5.2. 
A similar approach has been used in Meteor [5], the Parisian subway without 
driver, to develop some generic and reusable components. 

If the model is valuated for a simple example of network with two hosts, 
two daemons, one service and one user, then 31 proof obligations are generated 
and only 26 of them arc discharged by the automatic prover. The five remaining 
proof obligations have been interactively discharged, but are really obvious and 
only need two commands : replace (eh) and predicate prover (pp(rp.O)). 




[ Policy level 



Level 1 



LevelZ 




7 Conclusion 



Implementation 
Fig. 11. General model organisation 



This work has been done within the framework of the POTESTAT^ project 
[9], which aims at proposing a methodology for network security testing from 



^ Security policies: test directed analysis of open networks systems. 



high-level security policies. The main problem is to establish the conformity 
relation in order to automatically generate test cases and oracles from an abstract 
specification, as it has been implemented in the TGV tool [12] from IRIS A and 
Verimag french laboratories. 

Our contribution is a method to automatically enforce an abstract secu- 
rity policy on a network. In order to achieve that, we build a formal relation 
{Represents ^^q) between abstract and concrete levels. The dynamic part of the 
program [Check _event_and_Event_filter) computes all actions associated to each 
observed event. Finally, we guarantee, by using an observer (Get^status), that 
all violations and conflicts are detected at each refinement level (Property 1) 
and that no warning is issued for an event which is correct with respect to the 
policy (Property 2). 

The work of D. Senn, D. Basin and of G. Caronni [21] and of G. Vigna [23] 
are also dealing with the modeling of network conformity of a security policy. 
The model of [23] supports all the TCP/IP layers but does not provide a formal 
definition of the policy and needs human interaction to produce the test cases, 
while the model introduced in [21] only considers the first two layers and uses a 
low-level policy. 

In this paper, we described the development of a network monitor, and the 
same approach can be used for generation, verification or test of a network 
configuration. The relationship is built in the same way and only the dynamic 
part of the model has to be modified. 

In particular, many works have been developed relative to the generation of 
firewall configurations. For example, Firmato [4] is a tool generating the firewall 
configuration from a security policy and a network topology, and the POWER 
tool [18], of Hewlett-Packard, can rewrite a security policy into devices configu- 
ration. However, Firmato needs some topology information and uses a low-level 
policy, and POWER requires some human interactions during the process. The 
work presented here does not need human interaction (if all proof obligations 
are automatically discharged) or topology information. Due to the existence of 
the conflict status, it seems more adapted to the monitoring approach. 

Finally, in our model, the conflict case can be removed if Represents^^Q is a 
function from KnownNeti to KnownNeto-, as done in [8] with a security policy 
expressed in the OrBAC framework [14]. In order to achieve that, we have to 
recognize the user and the service associated to each event. It can be realistic to 
associate only one service to each port, but it is too strict to impose that each 
host can be used by only one user. An investigation should be done to properly 
compare their approach with ours. 

Acknov^fledgments. The authors would like to thank D. Bert, V. Darmaillacq, 
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